FIG. 1 is a generalized block diagram of a computer system 100 in the prior art. In the computer system 100, central processing unit (CPU) 105 communicates via bus interface 110 to system memory 115. I/O interface 130 receives user input from one or more user input devices 135 and forwards the input to CPU 105. Visual output is provided on display device 145 by way of graphics subsystem 140. System disk 120 is connected to I/O interface 130 or bus interface 110.
Clock generator 150 supplies clocks at a variety of frequencies to the various components of computer system 100. For example, clock generator 150 may provide a number of different clocks (e.g., at different frequencies) to drive the various hardware circuits within graphics subsystem 140. Clock generator 150 may supply a digital-to-analog converter (DAC, not shown) in graphics subsystem 140 with various clocks so that the DAC can generate an analog signal to display device 145, and may supply another circuit component such as I/O interface 130 with other clocks. The clocks are needed so that the various hardware circuitry in computer system 100 may perform their respective functions.
At any point in time, some circuitry modules in computer system 100 may be idle and not performing a useful function. While the module is idle, computer system 100 may disable clocks to the idle module in order to save power. For example, to extend battery life where computer system 100 is a laptop PC, a software power management component running on CPU 105 may command clock generator 150 to disable one or more of the clocks supplied to the idle module.
However, each of the individual software components running on CPU 105 may not always be coordinated or “aware” of the exact state of the modules in computer system 100. For example, a driver software component may operate independently of the power management software component. The driver may get stuck in a loop attempting to read status of an idle module, because if the idle module's clock is disabled, the module will not respond to the driver's request for status information. If the driver does not receive status information from the module, the driver may keep attempting to read the status of the module. In another example, to service an interrupt, an interrupt service routine running on CPU 105 might need to read registers in various modules distributed across computer system 100 to determine why the interrupt occurred, e.g., because of a context switch, an error, or a software semaphore that indicates that an event has concluded. The interrupt service routine might get stuck in a loop attempting to read status from idle modules, or may time out doing so.
Therefore, because each of the individual software components running on CPU 105 may be uncoordinated relative to the hardware modules in computer system 100, computer system 100 may require modules to remain on so that drivers, interrupt service routines, and the like can read the status of the modules. A module may be required to remain on even if the module might otherwise be disabled as not actively performing a useful function. Keeping the module on unnecessarily consumes power in computer system 100.